.,        .  - 


A  STUDY  INTO  THE  PROBLEM  OF  DEADLOCK 


Lesl ie  Ray  Conkl in 


Library 

Naval  Postgraduate  School 

Monterey,  California  93940 


a  L 


■■I 


^  , 


k» 


L 


Monterey,  California 


J    I 


A  STUDY  INTO  THE  PROBLEM  OF  DEADLOCK 


by 


Leslie  Ray  Conklin 


Thesis  Advisor: 


G.  L.  Barksdale,  Jr. 


Approved  loK  pubtic  KoXojViZ}   dUtnJJoLition  untlmltzd. 


T155111 


Library 

Naval  Postgraduate  Schoo! 

Monterey,  California  93940 


&   Study    into    the    Problem    of    Deadlock 


by 


Leslie  Bay  Conklin 
5tc 


Captain,  United  States  Marine  Corps 
B.  S.,  University  of  Missouri,  1965 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  COMPUTER  SCIENCE 


from  the 

NAVAL  POSTGRADUATE  SCH00I 
June,  1973 


I    '! 


AESTBACT 


This  paper  presents  a  study  of  the  problem  of  system 
deadlock  with  emphasis  on  the  allocation  of  serially 
reusable  resources.  The  initial  area  of  concentration  is  on 
a  definition  of  system  deadlock  and  a  presentation  of  proven 
methods  cf  handling  deadlock.  After  the  discussion  of 
current  theory,  two  major  operating  systems  are  examined. 
An  overall  description  of  the  functioning  of  OS/360  is 
presented  followed  by  a  detailed  discussion  of  the 
procedures  used  by  OS/360  to  allocate  serially  reusable 
resources.  The  Michigan  Terminal  System  is  then  discussed, 
outlining  the  techniques  of  resource  allocation  employed. 
The  paper  is  concluded  by  correlating  the  methods  used  in 
OS/ 36  0  with  those  of  MTS. 
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I.   INTRODUCTION 


In  the  present  age  of  the  computer  there  is  an  ever 
increasing  demand  for  computer  power.  To  some  extent  this 
demand  has  been  fulfilled  by  using  bigger  and  faster 
computers,  but  economic  constraints  have  dictated  that 
computers  must  also  be  efficient.  The  efficient  utilization 
of  computers  is  often  achieved  through  multiprogramming. 

In  a  multiprogramming  environment  several  processes  are 
active  concurrently;  ccnseguently,  there  is  new  an 
interaction  between  processes  as  they  compete  for  system 
resources.  When  several  processes  compete  for  resources  it 
is  possiLIe  that  more  than  one  process  will  require  a  given 
resource  at  some  point  in  time.  In  this  situation  one 
process  will  be  given  control  of  the  resource  in  question, 
and  all  ether  processes  will  be  blocked  until  the  resource 
again  becomes  available.  If  two  or  more  processes  are 
mutually  blocking  each  other  from  further  execution  the 
situaticn  is  known  as  deadlock. 

An  investigation  of  the  problem  of  system  deadlock  is 
undertaken  in  this  thesis.  A  study  of  available  literature 
on  deadlock  was  conducted  to  determine  what  has  been  done  in 
this  area.  An  attempt  is  made  to  consolidate  this 
information  into  a  unified  presentation  of  current  theory. 
A  second  objective  was  to  closely  examine  two  major 
operating  systems  to  determine  which  deadlock  strategies 
have  been  employed  in  each  and  what  methods  were  used  in 
their  implementation.  The  two  operating  systems  selected 
for  this  study  were  IBM's  OS/360  and  the  University  of 
Michigan's  Michigan  Terminal  System  (MTS) . 


II.   CURRENT  THEORY 


In  studying  the  current  literature  on  the  subject  of 
system  deadlock  it  is  evident  that  there  are  a  limited 
numher  cf  authors  in  this  area.  It  also  appears  that  these 
authors  are  very  much  in  agreement  on  the  basic  facts.  The 
variance  is  encountered  in  nomenclature  and  representation 
methods.  While  one  author  [Habermann  1969]  prefers  a  vector 
notation  and  uses  matrix  manipulation  to  define  deadlock, 
another  [Holt  1971]  [Holt  1972]  prefers  a  graphic 
representation  and  defines  deadlock  accordingly. 

As  a  result  of  reading  much  of  the  current  literature 
the  authcr  has  developed  a  view  of  the  deadlock  problem 
which  includes  points  presented  by  several  writers.  The 
following  is  a  presentation  of  that  view. 

A.   DEADLOCK  DEFINITION 

A  simple  instance  of  deadlock  occurs  when  two  processes, 
P1  and  P2,  use  two  common  resources,  R1  and  R2.  Assume  that 
each  process  requests  resources  as  they  are  needed  and 
further  assume  that  a  resource  cannot  be  released  by  a 
process  which  is  waiting  for  a  reguested  resource.  Suppose 
process  P1  has  resource  R1  allocated  to  it  and  requests  R2; 
process  12  has  resource  R2  allocated  to  it  and  requests  R1. 
This  is  a  deadlock  situation  because  by  requesting  the  same 
two  resources  in  reverse  order  each  process  has  made  a 
reguest  which  cannot  be  satisfied. 

The  simple  case  of  system  deadlock  has  been  extended  to 
include  any  number  of  processes  and  resources  [Holt  1971] 
[Holt   1972].   Holt  has  presented  a  number  of  theorems  which 


define  necessary  and  sufficient  conditions  for  deadlock. 
For  a  complete  description  based  on  graph  theory  methods  the 
reader  should  refer  to  [Holt  1971].  In  general  terras, 
deadlock  will  occur  in  any  situation  in  which  there  is  a 
closed  locp  of  processes  each  requesting  a  resource  (s) 
allocated  to  another  process  within  the  loop. 

Although  deadlock  can  occur  from   any   type   of  process 

interaction,   we   shall  emphasize  the  allocation  of  serially 

reusable  resources  since  most  system  resources  are  serially 

reusable   [Havender   1968].    Some   examples   are:  storage 
media,  systeir  components,  and  information. 

Storage  media  (such  as  main  memory,  tape,  and  disk  or 
drum  tracks)  are  considered  to  be  serially  reusable  because 
they  contain  only  one  set  of  information  at  a  time.  When 
that  set  cf  information  is  no  longer  needed,  the  media  can 
be  used  again  to  hold  a  new  set  of  information. 

Systeir  components  (such  as  tape  drives,  disk  drives, 
central  processing  units,  and  access  mechanisms)  are 
serially  reusable  because  they  are  generally  dedicated 
totally  to  one  process  at  a  time.  One  might  argue  that  a 
disk  drive  may  have  a  disk  containing  information  for  many 
processes  and  should  therefore  be  considered  shareable. 
This  is  true,  but  if  the  volume  contains  only  information 
for  one  specific  application  it  can  be  considered  serially 
reusable. 

Information  is  intrinsically  shareable,  unless  it  is 
defined  as  net  shareable  for  security  reasons.  Information 
becomes  serially  reusable  when  it  is  being  changed.  When 
one  process  is  updating  a  record,  no  other  process  can 
access  that  record  until  the  update  has  been  completed. 
This   particular   problem   has   been   termed   the   "critical 


section"   problem   and   has   been   the   subject   of   its  own 
solutions  [Dijkstra  1965]. 

Serially  reusable  resources  can  be  characterized  ty  the 
following  five  properties  [  Cof f man  1971]  [Holt  197  1]  [Holt 
1972]. 

(1)  There  is  a  fixed  number  cf  units  of  each  resource. 
When  all  of  the  units  of  a  given  resource  have  been 
allocated  no  further  requests  can  be  fulfilled. 

(2)  Each  unit  of  a  resource  is  either  assigned  to  a 
particular  process  or  is  available  for  assignment. 

(3)  A  unit  of  a  resource  can  be  allocated  to  at  most  one 
process  at  a  time. 

(4)  A  process  can  release  any  resource  which  it  has 
acguired  but  not  yet  released. 

(5)  A  resource  assigned  to  a  process  can  not  be 
pre-empted  by  another  process.  Once  a  resource  has  been 
acquired  it  does  not  become  available  until  it  is 
released  by  the  process  which  holds  it. 

B.   DEADLOCK  STRATEGIES 

Any  system  in  which  processes  compete  foi  resources  must 
have  a  strategy  for  handling  the  deadlock  problem.  These 
deadlock  strategies  aelong  to  one  of  three  classes: 
prevention,  detection,  or  crash  [Holt  1971]  [Holt  1972  1. 

1 •  EE& mention 

Under  deadlock  prevention  the  system  is  designed  in 
such  a  way  that  deadlock  is  not  possible.  As  would  be 
expected,  prevention  algorithms  tend  to  be  overly 
restrictive.   In  many  cases  a  process'  request  for  resources 


is   not   granted   even   though  such  action  would  not  lead  to 
deadlock. 

The  simplest  prevention  algorithm  is  tc  allow 
execution  of  hut  one  process  at  a  time.  This  method 
certainly  prevents  system  deadlock,  but  it  also  prevents 
multiprogiamcing. 

A  second  means  of  deadlock  prevention  requires 
collective  requests  for  resources.  A  process  must  acguire 
all  the  resources  it  will  use  before  it  begins  to  execute. 
In  this  case  a  running  process  can  never  be  blocked  by  an 
outstanding  request  for  resources.  As  each  process 
terminates  it  releases  its  resources  and  thereby  insures 
that  a  blocked  process  will  eventually  acquire  its 
resources.  The  obvious  disadvantage  of  collective  requests 
is  that  many  resources  may  be  allocated  long  before  they  are 
used,  thereby  denying  their  use  by  other  processes. 

A  third  method  of  deadlock  prevention  Hakes  it 
possible  to  avoid  allccating  resources  long  before  they  are 
used.  Under  this  method  a  process  holding  formerly  obtained 
resources  must  release  those  resources  before  requesting  an 
additional  resource.  If  any  of  the  original  resources  are 
still  reguired  they  must  be  re-requested  along  with  the 
additional  resource  [ Havender  1968]. 

A  more  complicated  method  is  known  as  ordered 
resources  [Havender  1968]  [Holt  1971]  [Holt  1972]. 
Resources  are  partitioned  into  k  classes,  numbered 
1,2/...,k.  A  process  is  allowed  to  reguest  resources  in 
class  i  only  if  it  has  not  already  been  allocated  resources 
in  classes  i,  i+1,  ...,  k.  Deadlock  is  prevented  because 
two  processes  cannot  cequest  the  same  resources  in  different 
order  as  described  in  the  initial  example.  Any  process 
which  holds  a  class  k  resource  cannot  be   blocked   and   will 


eventually  release  its  resources.  Consequently,  any  process 
holding  class  k- 1  resources  (and  can  only  request  class  k 
resources)  will  receive  its  requested  units  and  can  procede 
to  termination.  This  reasoning  can  be  extended  to  verify 
that  any  process  holding  resources  of  any  class  will 
eventually  receive  all  of  its  requested  units  and  therefore 
will  never  reach  a  deadlock  situation. 

Using  ordered  resources,  the  more  valuable  a 
resource  is,  the  higher  its  class  should  be.  Resources  in 
class  k  can  be  requested  when  actually  needed  and  released 
as  soon  as  they  are  not  needed.  Thus  the  higher  the  class 
of  a  resource  the  more  efficiently  it  is  used. 

2  -   Detect ion 

As  the  name  implies,  this  strategy  allows  deadlocks 
to  occur  and  takes  corrective  action  when  a  deadlock  is 
detected.  Deadlock  detection  algorithms  have  been  presented 
which  examine  the  status  of  the  system  at  any  given  instant 
to  determine  when  corrective  measures  are  reguired  [ Cof f man 
1971]  [Holt  1971]  [Holt  1972].  Once  a  deadlock  has  been 
detected  the  system  can  recover  by  terminating  the 
deadlocked  processes  or  by  pre-empting  resources  from 
processes.  Usually  it  is  not  necessary  to  terminate  all  of 
the  deadlocked  processes  to  recover.  As  soon  as  one  of  the 
processes  acquires  enouqh  resources  to  begin  execution  the 
deadlock  has  been  broken. 

The  obvious  question  which  arises  is  which  process 
is  to  be  the  one  terminated  or  to  have  its  resources 
pre-empted?  It  would  be  desirable  to  chose  the  process  with 
the  lowest  associated  cost.  This  cost  could  be  defined  as 
the  cost  of  restartinq  the  job  and  runninq  it  again  to  the 
point  of  termination  or  pre-emption.  The  difficulty 
encountered  is  determining  this  cost.   It  is  not   enough   to 


simply  consider  the  amount  of  computer  time  used  fcy  the 
process  up  to  this  point,  but  one  must  also  consider  the 
integrity  of  the  data  involved.  It  is  possible  that 
terminating  a  process  may  result  in  a  major  effort  to 
restore  the  data  base  to  its  original  form. 

Another  method  of  determining  restart  cost  would  be 
to  break  down  all  processes  into  classes,  each  with  an 
arbitrarily  assigned  cost.  For  example,  in  an  academic 
environment  the  classes  might  be;  student  jobs,  staff 
research  jobs,  and  system  jobs.  In  this  case  the  students 
processing  would  be  the  first  terminated  or  pre-empted. 

This  strategy  can  allow  higher  resource  utilization 
than  is  possible  when  deadlock  is  entirely  prevented.  It  is 
the  preferred  method  in  those  systems  where  deadlock  is 
infreguent  and  the  cost  of  recovery  is  not  prohibitive. 

3 .   Crash 

Under  this  strategy  deadlocks  are  neither  prevented 
nor  detected  by  the  operating  system.  It  is  the 
responsibility  of  the  computer  operator  to  determine  when  a 
deadlock  has  occurred  and  to  take  appropriate  steps  to 
remove  it.  The  only  possible  advantage  of  this  strategy  is 
that  it  saves  the  time  and  space  required  by  the  prevention 
and  detection  routines. 
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III.   OPERATING  SYSTEM/3  6  0 


The  presentation  on  IBM's  Operating  System/360  (CS/360) 
is  based  primarily  on  information  obtained  from  IBM  program 
logic  manuals.  These  manuals  deal  with  the  operating  system 
functions  at  a  very  detailed  level  and  hence  were  adequate 
for  the  purposes  of  this  paper.  The  primary  drawback  of 
these  manuals  is  that  they  are  replete  with  abbreviations 
and  consequently  are  difficult  to  comprehend. 

The  discussion  on  deadlock  prevention  in  OS/360,  as  it 
pertains  to  serially  reusable  resources,  is  essentially  a 
discussion  of  job  initiation.  It  is  during  the  initiation 
of  a  job  step  that  all  serially  reusable  resources  are 
allocated,  and  thus  where  the  deadlock  prevention  algorithms 
are  encountered.  Before  a  detailed  description  of  the 
initiator  is  given,  it  is  appropriate  to  briefly  describe 
the  general  structure  and  functions  of  OS/360. 

A.   GENERAL  ORGANIZATION 

The  operating  system  is  divided  into  three  major 
functional  areas:  job  management,  task  management,  and  data 
management. 

The  primary  functions  of  job  management  are:  analysis 
of  the  job  stream,  overall  scheduling,  allocation  of 
input/output  devices,  and  direction  of  setup  activities 
[Witt  1966],  The  functions  of  job  management  are 
accomplished   by  the  master  scheduler  and  the  job  scheduler. 

The  master  scheduler  serves  as  a  communication  control 
link   between   the   operator   and   the  system.   It  processes 
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commands  from  the   operator   to   the   operating   systeir   and 
outputs   iressages  from  the  system  to  the  console  typewriter. 

The  job  scheduler  consists  of  three  primary  elements: 
the  reader/interpreter,  the  initiator/terminator,  and  the 
system  writer.  The  reader/interpreter  reads  the  input 
stream,  converts  the  control  statements  into  tabular  form 
and  places  them  into  the  job  input  queue.  The  initiator 
selects  the  highest  priority  job  from  the  input  gueue, 
obtains  a  region  of  main  storage,  collects  the  required  data 
sets,  allocates  I/O  devices,  and  turns  the  job  step  over  to 
task  management.  Upon  completion  of  execution,  the 
terminator  directs  the  disposition  of  data  sets  and  releases 
the  I/O  devices  for  allocation  to  other  tasks.  The  system 
writer  takes  the  output  data  sets  produced  by  the  jot  step 
from  the  output  queue  and  puts  them  to  the  appropriate 
output  device. 

Task  management  controls  the  job  step  during  its 
execution.  The  functions  of  task  management  consist  of  the 
fetching  of  required  load  modules;  the  dynamic  allocation  of 
CPU,  storage  space,  channels,  and  control  units  on  behalf  of 
competing  tasks;  the  services  of  the  interval  timer;  and  the 
synchronization  of  related  tasks  [Witt  1966]. 

The  data  management  programs  are  primarily  responsible 
for  moving  information  between  main  storage  and  external 
storage  and  maintaining  it  in  external  storage.  This  is 
achieved  by  maintaining  the  system  catalogue,  providing 
various  access  methods  and  buffering  techniques,  processing 
volume  labels,  and  protecting  data  via  passwords  [Clark 
1966]. 

The  above  description  of  OS/360  was  intended  only  to 
provide  a  basic  view  of  the  environment  surrounding  the 
system   modules   to  be  discussed  later.   For  a  more  complete 
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description  the  reader  should  consult  the  above  cited 
references  and/or  the  IBM  manual.  Operating  System 
Introduction  [  IBM  1971]- 

B.   RESOURCE  ALLOCATION 

The  discussion  on  resource  allocation  is  presented  on 
two  different  levels.  The  first  level  is  general  in  nature 
and  covers  key  points  involving  resource  allocation  and 
deadlock  prevention.  The  second  level  appears  as  Appendix  C 
and  gives  a  detailed  module  by  module  description  of  the 
actions  of  the  initiator.  To  aid  those  readers  not  familiar 
with  IBM  systems,  Appendix  A  contains  a  glossary  of  IBM 
terms  and  Appendix  B  contains  a  description  of  relevant  IEM 
system  macro  instructions. 

The  basic  mechanism  for  controlling  a  resource  is  a  pair 
of  macro  instructions,  ENQ  and  DEQ.  ENQ  reguests  the  use  of 
a  resource  and  specifies  whether  the  ccntrol  is  to  be 
exclusive  or  shared.  DEQ  is  used  to  free  resources  obtained 
by  the  use  of  an  ENQ. 

The  initiator  is  used  to  start  both  system  tasks  and  job 
step  tasks.  To  initiate  a  task  the  initiator  retrieves  job 
control  information  about  the  task  and  reserves  system 
resources  for  the  use  of  the  task.  After  resource 
allocations  are  completed,  the  initiator  passes  control  to 
the  task.  On  task  completion,  the  termination  routine  of 
the  initiator  releases  all  of  the  task's  system  resources. 
The  actions  of  the  initiator  during  the  initiation  of  a 
typical  jot  are  discussed  below. 

1  •  0.9k    Selection 

Ihe  first  function  of  the  initiator  is  to   select   a 
job   from   the   input   queue   containing   jobs   arranged   by 
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priority  within  job  class.  To  do  this,  the  initiator  uses 
the  ENQ  macro  to  obtain  exclusive  control  of  the  queue 
control  record.  Once  the  initiator  gains  control  of  the 
queue  ccntrcl  record,  it  examines  it  to  determine  if  there 
are  any  jobs  in  the  queue  of  the  class  serviced  by  this 
particular  initiator.  If  so,  the  highest  priority  job 
within  the  class  is  selected.  The  initiator  then  issues  a 
DEQ  which  permits  access  to  the  queue  control  record  by 
other  routines. 

The  initiator  then  determines  how  irany  steps  are  in 
the  job  and  what  data  sets  will  be  required.  Next  it 
prepares  a  parameter  list  for  the  ENQ  macro  specifying  each 
data  set  name  and  whether  its  use  is  exclusive  or  shareable. 

2-   Rjgicn  Ma  nagement 

The  initiator  then  determines  the  amount  of  main 
storage  required  by  the  job  step  and  issues  the  ENQ  fcr  its 
data  sets.  If  all  of  the  data  sets  cannot  be  obtained,  the 
initiator  issues  a  DEQ  to  free  those  which  were  obtained. 
This  prevents  possible  deadlock  between  jobs  with 
overlapping  data  set  requirements.  At  this  point  the 
operator  is  given  the  option  of  retrying  the  ENQ,  cancelling 
the  job,  or  waiting  for  the  data  sets  to  become  available. 

When  all  data  sets  have  been  secured,  the  initiator 
then  reguests  the  region  of  main  storage.  When  the  region 
has  been  obtained,  device  allocation  begins. 

3»   I/O  Device  Allocation 

The  operating  system  contains  a  table  cf  unit 
control  blocks.  Each  unit  control  block  contains  all  of  the 
information  about  a  specific  device  that  the  initiator  needs 
to   make   device   allocations.   In  order  to  prevent  multiple 
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;ses  to  the  unit  control  blocks  during   allocation,   the  q 

.ator   uses   the   ENQ   to  get  exclusive  control  of  them.  Q 

3NQ  net  only  prevents  simultaneous  allocation  of  devices  L 

ore  than  one  job  step,  but  also  prevents  the  terminator 

freeing  any  devices. 

i 

If  allocation  cannot  be  completed  because  of  lack  of  £ 

es,  the  operator  is  given  the  option  of  cancelling   the  s 

making  a  device  available  which  is  offline,  or  waiting  ^ 

levices  to  become  available.    If   the   wait   option   is  ^ 

cted,   the   unit   control   blocks   are   DEQ'ed   and   the  i 

iator   waits   until   another   task   terminates,   thereby  L 

ing  its  devices.   Allocation  is  then  attempted  again.  1 
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When  all  devices  have  been  allocated   the   initiator  ) 

es   a  DEC  on  the  unit  control  blocks  and  the  job  step  is  ^ 

ied  fcr  execution. 

4-   J ask  germination 

When  a  task  reaches  normal  completion  or  abnormally 
execution,  it  is  handled  by  the  terminator,  which  acts 
i  subroutine  of  the  initiator.  The  terminator  performs 
required  data  set  disposition  and  frees  the  I/O  devices. 
Eree  the  devices  the  terminator  must  use  the  ENQ  to  gain 
Lusive  control  over  the  unit  control  blocks.  After  all 
Lees  have  been  freed,  the  terminator  then  issues  a  DEQ  to 
ease  the  unit  control  blocks.  The  initiator  is  now  free 
process  the  next  job  step. 

SUMMAEY 

The  atove  study  of  OS/360  has  revealed  quite  clearly 
t  deadlock  strategies  have  been  incorporated  into  this 
rating  system.   The  designers  of  this  system  have   chosen 

prevent   deadlock   rather   than  to  let  it  occur  and  then 
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take  corrective  action.  It  was  probably  their  conclusion 
that,  under  the  vast  range  of  computing  environments  in 
which  OS/36Q  is  used,  preventing  deadlock  was  more  practical 
than  implementing  detection  algorithms. 

The  methcd  of  deadlock  prevention  used  in  OS/360  is  a 
comtinaticn  of  two  methods  discussed  at  the  beginning  of 
this  paper.  The  two  methods  are  known  as  collective 
resources  and  ordered  resources.  The  method  of  collective 
resources  is  applicable  because  a  task  must  obtain  all  the 
resources  it  will  use  before  it  begins  to  execute.  The 
method  of  ordered  resources  comes  into  play  in  that  all 
resources  are  divided  into  three  classes;  data  sets,  main 
storage,  and  I/O  devices.  During  allocation  main  storage  is 
net  requested  until  all  data  sets  have  been  acquired;  I/O 
devices  are  not  reguested  until  al},  data  sets  and  main 
storagej  have  been  obtained. 
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IV.   MICHIGAN  TERMINAL  SYSTEM 


It  was  planned  tbat  this  section  of  the  thesis  would 
contain  a  study  of  the  Michigan  Terminal  System  (MTS) 
comparable  tc  that  presented  for  OS/360-  This  study  was  to 
be  carried  out  in  connection  with  the  implementation  of  MTS 
on  the  Naval  Postgraduate  School  computer.  However,  MIS  was 
undergoing  revision  at  the  University  of  Michigan  and  delays 
in  its  distribution  precluded  such  a  study. 

In  the  absence  of  the  current  release  of  MTS  and  its 
associated  documentation  a  much  more  limited  effort  was 
conducted.  The  primary  sources  of  information  were  the 
computing  center  newsletter  and  memos  published  by  the 
University  of  Michigan,  various  articles  written  by  the 
designers  of  MTS,  an  assembly  listing  of  a  prior  version  of 
MTS,  and  telephone  contact  with  the  staff  at  the  University 
of  Michigan. 

A~   GENERAL  ORGANIZATION 

MTS  is  an  operating  system  which  offers  both  batch  job 
and  terminal  usage.  It  was  designed  to  take  advantage  of 
the  special  relocation  hardware  and  multiple  central 
processors  offered  by  the  IBM  360  model  67.  In  crder  to 
facilitate  extension  and  modification,  the  system  is 
organized  as  a  set  of  independent  components  with  well 
defined  interfaces.  The  four  primary  components  are  the 
University  of  Michigan  Multi-Programming  Supervisor  (UMMPS) , 
the  Paging  Drum  Processor  (PDP) ,  the  Michigan  Terminal 
System  (MTS) ,  and  a  highly  modified  version  of  the  Houston 
Automatic  Spooling  Priority  system  (HASP) . 
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UMMPS  is  a  set  of  subroutines  which  run  in  privileged 
state  with  interrupts  disabled.  All  entries  tc  the 
supervisor  are  made  through  interrupts  and  are  processed  to 
completion  before  giving  up  the  processor  [Alexander  197 1 j. 
It  processes  all  interrupts;  does  all  physical  input/output; 
allocates  and  schedules  devices,  main  storage,  and  CPU's; 
and  provides  inter-task  communication  and  protection 
[Eoettner  1 970]  [ Alexander  1971]. 

The  PDP  runs  under  the  control  of  the  supervisor  and  is 
responsible  for  maintaining  external  page  storage  and  for 
moving  pages  between  main  storage  and  auxiliary  storage 
[Eoettner  1970]  [Alexander  1971].  The  auxiliary  storage 
used  is  cne  or  more  drums  or  disks;  these  devices  are  under 
the  complete  control  of  the  PDP. 

MTS  is  a  re-entrant  program  which  is  activated  once  for 
each  terminal  in  the  system  and  once  for  each  running  batch 
jot  [ Boettner  1970].  In  effect  each  user  in  the  system  has 
his  own  private  copy  of  MTS.  It  provides  device  support 
routines,  performs  file  handling  functions,  does  command 
processing,  and  interfaces  input/output  with  HASP. 

HASP  is  a  non  re-entrant  program  which  controls  the  card 
readers,  punches,  and  printers  on  the  system  and  maintains 
the  input/output  spool  queue.  The  modifications  to  HASP 
have  transformed  it  into  a  batch  monitor.  As  such  it 
generates  MTS  batch  tasks  and  starts  them  executing.  The 
number  of  batch  jobs  executing  at  any  one  time  depends  upon 
the  system  load  [Boettner  1970], 

B.   RESOURCE  ALLOCATION 

Our  discussion  of  allocation  under  MTS  will  be  based  on 
the  type  of  resource  being  allocated,  specifically,  main 
storage,  files,  and  I/O  devices. 
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1 .   Mai n  Storage 

The  task  of  moving  pages  between  main  storage  and 
auxiliary  storage  is  shared  by  UHflPS  and  the  PDP.  UMMPS 
determines  which  pages  are  to  he  read  into  memory  or  mitten 
out  to  druro  and  the  PDP  does  the  reading  or  writing. 
Communication  between  UMMPS  and  the  PDP  is  accomplished  by 
placing  a  Page  Control  Block  (PCB)  on  one  of  four  gueues: 
the  Page  In  Queue  (PIQ) ,  the  Page  In  Complete  Queue  (PICQ) , 
the  Page  Cut  Queue  (POQ) ,  or  the  Release  Page  Queue  (RPQ) 
[Alexander  1971].  An  explanation  of  these  gueues  and  the 
PCB  is  contained  in  Appendix  D. 

Ihe  PDP  utili2es  five  supervisor  calls  in  its  normal 

operation.   These  supervisor  calls,  described  in  Appendix  E, 

are:    Get   Real   Page  (GETRP) ,  Free  Real  Page  (FREEBP) ,  Get 

Write  Page  (GETWP) ,   PDP   Wait   (PDPWAIT) ,   and   Get   Queues 

(GE1QS)  [Alexander  1971]. 

When  the  supervisor  determines  that  a  page  must  be 
read  into  main  storage  it  will  place  the  PCB  for  that  page 
on  the  PIQ.  likewise,  the  supervisor  will  place  pages  which 
have  been  released  by  their  tasks  on  the  RPQ  and  pages  which 
could  be  removed  if  necessary  on  the  POQ.  After  placing  a 
page  on  the  PIQ  the  supervisor  will  start  the  PDP,  if  it  is 
idle. 

The  PDP  will  call  the  GETQS  subroutine  which  will 
return  all  PCB's  on  the  PIQ  and  the  RPQ.  It  next  calls 
GETEP  to  obtain  a  main  storage  block  to  read  each  page  into. 
In  the  event  that  no  block  is  available,  the  GETWP  routine 
will  return  pages  to  be  written  and  main  storage  will  become 
available. 
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When  the  PDP  has  obtained  a  block  for  each  page  to 
be  read  in,  it  constructs  a  channel  program  which  will  read 
the  required  pages  into  main  storage.  The  channel  program 
is  generally  constructed  to  accommodate  nine  pages  at  a 
time.  If  all  nine  slots  are  not  filled  by  read  requests, 
the  PDP  will  call  GETWP  to  attempt  to  get  enough  pages  to 
fill  the  unused  slots  with  writes. 

When  the  channel  program  has  been  constructed  for 
all  the  reads  and  writes,  it  will  be  queued  for  execution. 
During  execution  of  the  channel  program,  a  program 
controlled  interrupt  is  generated  as  each  page  transfer  is 
completed.  These  interrupts  are  not  queued  and  are  lost  if 
not  serviced  immediately.  At  the  end  of  the  channel 
program,  however,  an  interrupt  occurs  which  is  queued. 
Interrupts  of  either  type  signal  the  PDP.  The  PEE  then 
places  the  PCB's  for  pages  read  on  the  PICQ  and  calls  EREERP 
to  release  the  main  storage  blocks  for  all  pages  written. 
The  supervisor  will  detect  the  pages  on  the  PICQ  the  next 
time  it  is  entered  and  will  restart  the  tasks  waiting  for 
them. 

The  PDP  also  has  the  ability  to  detect  unnecessary 
reads  and  urites  and  eliminate  them.  Por  example,  if  a  page 
has  not  been  changed  since  it  was  last  read  in,  there  is  no 
need  to  write  it  back  out  again.  By  the  same  reasoning,  if 
a  page  is  reguested  again  before  it  has  teen  freed  fcy  the 
PEP,  the  copy  already  in  main  storage  can  be  used. 


Files 


MIS  supports  the  concept  of  shared  files.  After  a 
user  creates  a  file  he  has  the  ability  to  specify  which 
other  users  nay  have  access  to  this  file  and  what  type  of 
access   they   may  have.   The  owner  of  the  file  can  limit  the 
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access  to  himself,  to  other  users  by  individual  user 
identification  numbers,  to  other  users  by  project  number,  to 
all  other  users,  or  to  any  combination  of  the  above  [U  of 
Mich  1972b].  As  the  owner  of  the  file  specifies  who  has 
access  he  also  defines  the  extent  of  the  access.  The 
various  degrees  of  access  to  a  file  are:  the  ability  to 
read  from,  the  ability  to  add  to  but  not  change  existing 
information  in  the  file,  the  ability  to  change  or  delete  but 
not  add  to,  the  ability  to  truncate  or  renumber,  the  ability 
to  destroy  or  rename,  the  ability  to  modify  the  right  of 
access,  or  a  combination  of  the  above  [0  of  Mich  1972b]. 

Ihe  system  controls  the  concurrent  use  of  shared 
files  by  maintaining  a  system  wide  shared  file  table.  This 
table  contains  an  entry  for  each  file  currently  in  use  which 
describes  how  and  by  whom  each  file  is  being  used.  The 
system  also  requires  that  a  file  must  be  locked  in  the 
appropriate  manner  before  any  operation  can  be  performed  on 
that  file  [U  of  Mich  1972a]. 

MTS  provides  three  level  of  locking.  The  lowest 
level  is  locking  a  file  for  reading.  The  second  level  is 
locking  a  file  for  modification,  which  includes  adding, 
changing,  deleting,  truncating  and  renumbering.  The  highest 
level  of  locking  a  file  is  for  destroying;  this  includes 
renaming  and  changing  the  rights  of  access.  At  each  level 
of  locking  the  user  also  has  the  file  locked  for  the 
operations  allowed  by  any  lower  level  of  locking  [ U  cf  Mich 
1972a].  As  is  normally  true,  any  number  of  users  may  have  a 
file  locked  for  reading,  but  when  a  user  has  a  file  locked 
for  modification  or  for  destroying  he  must  have  exclusive 
use. 

When  a  user  requests  a  file,  MTS  determines  whether 
or  not  he  has  been  granted  access  by  the  cwner  of  the  file 
and,  if  so,   has   he   been   granted   the   degree   of   access 
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requested.  If  the  answer  to  the  two  atcve  questions  is 
afirmative,  MTS  then  consults  the  shared  file  table  to 
determine  if  the  required  level  of  locking  can  te  made 
without  violatinq  the  rules  requirinq  exclusive  control.  If 
so  the  file  is  locked  as  requested. 

If  another  task  already  has  the  file  locked  and  the 
current  request  cannot  be  honored,  MTS  will  enqueue  the  task 
on  the  file  and  put  it  in  a  wait  until  the  file  can  be 
locked.  Before  enqueueinq  the  task,  MTS  will  ensure  that 
placinq  the  task  on  the  queue  will  not  result  in  a  deadlock 
situation.  Perhaps  this  can  best  be  illustrated  through  the 
use  of  an  example. 

Consider  a  situation  similar  to  the  one  presented  on 
page  five.  Assume  that  task  T1  has  file  F1  locked  for 
reading  and  that  task  T2  has  file  F2  locked  for  reading. 
Now  suppose  task  T1  requires  file  F2  to  be  locked  for 
modification.  MTS  will  determine  that  F2  is  locked  for 
reading  and  will  queue  T1  to  wait  until  T2  has  completed  its 
use  of  F2. 

If  at  this  point  T2  now  has  a  requirement  to  modify 
F1,  MTS  will  determine  that  puttinq  T2  en  a  queue  to  wait 
for  file  P1  would  result  in  deadlock.  Therefore,  it  will 
net  place  task  T2  on  the  queue,  but  will  instead  indicate 
that  an  error  condition  exists. 

What  happens  as  a  result  of  the  error  condition 
depends  upon  the  type  of  job  involved.  If  T2  is  a  batch 
job,  it  will  be  terminated,  releasinq  all  of  its  resources. 
It  will  then  be  returned  to  the  HASP  input  queue  in  a  hold 
status  to  be  released  by  the  operator  to  rerun  at  a  later 
time.  If  T2  is  a  terminal  job,  an  error  message  will  be 
sent  to  the  user  indicating  the  deadlock  situation  and  he 
must  decide  what  corrective  action  is  to  be  taken. 
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3  -  IzQ.   Qz lice s 

MIS  in  general  divides  its  I/O  devices  into  two 
classes.  Cne  class  consists  of  unit  record  devices  such  as 
the  card  readers,  punches,  and  printers;  the  other  class 
consists  of  all  other  devices. 

The  unit  record  devices  are  controlled  by  HASP. 
When  a  task  requires  a  unit  record  device  it  is  assigned  a 
pseudo-device.  As  the  task  reads  from  or  writes  tc  this 
pseudo-device  it  is  actually  reading  from  or  writing  to  the 
HASP  spool  queue.  HASP  in  turn  performs  the  I/O  operation 
to  a  physical  device  as  devices  become  available,  assigning 
the  tasks  on  a  priority  basis. 

Other  devices  can  be  allocated  either  befcre  the 
task  begins  execution  or  during  the  execution  of  the  task. 
The  time  allocation  takes  place  is  determined  by  the  method 
employed  by  the  user  in  requesting  the  device.  If  the  user 
prefers  that  allocation  take  place  before  execution  begins, 
he  must  use  a  system  command  which  invokes  the  MOUNT 
program.  If  allocation  is  to  take  place  as  needed  during 
execution,  the  MOUNT  program  is  called  as  a  subroutine. 

In  either  case  the  MOUNT  program  is  supplied  with 
the  type  cf  device  required  and  the  name  of  the  file  to 
mounted  on  the  device.  The  MOUNT  routine  issues  a  message 
to  the  console  operator  requesting  a  device  by  type  and 
indicating  the  volume  to  be  placed  on  that  device.  If  the 
operator  can  determine  that  there  are  not  enough  devices 
available  to  satisfy  the  allocation  request,  he  can  at  this 
time  so  indicate.  Ey  doing  so  he  forces  a  batch  jot  to  be 
returned  to  the  HASP  input  gueue,  or  forces  a  terminal  user 
to  decide  on  an  alternate  course  of  action. 
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If  devices  are  available,  the  operator  responds  with 
a  specific  device  address.  The  MOUNT  routine  then  issues  an 
SVC  to  enter  the  UMMPS  allocation  routine  which  attempts  to 
allocate  the  named  device.  If  the  device  is  available,  it 
is  allocated  and  the  operator  is  given  confirmation. 

In  the  event  that  the  device  named  by  the  operator 
has  already  been  allocated,  is  inoperable,  or  has  been 
varied  offline,  an  error  condition  is  indicated.  The 
response  to  this  error  condition  is  the.  same  as  that 
previously  described  for  files. 

C.   SUMMARY 

The  above  study  of  MTS  does  not  reveal  a  clearly  defined 
deadlock  strategy.  The  allocation  method  encountered  is 
different  for  each  type  of  resource  involved  and  there  does 
not  appear  to  be  any  interrelationship  between  them. 
Consequently,  the  deadlock  strategy  is  at  best  difficult  to 
pinpoint . 

Of  the  three  deadlock  strategies  described  in  the  early 
part  of  this  paper,  prevention  is  the  most  appropriate  to  be 
associated  with  MTS.  However,  MTS  does  not  employ  any  of 
the  methods  of  prevention  previously  discussed.  In  spite  of 
this  fact,  there  is  evidence  supporting  the  choice  of 
deadlock  prevention  as  the  strategy  incorporated  by  MTS. 

The  most  convincing  evidence  is  displayed  by  the  locking 
technigue  used  in  the  control  of  files.  Eefore  a  task  is 
queued  on  a  file,  the  system  checks  to  see  if  such  gueueing 
would  result  in  deadlock.  If  so,  the  task  is  not  queued  and 
deadlock  is  prevented. 

A  mere  subtle  prevention  technique  is  encountered  in  the 
allocation  of  main  storage.   Paging  of  main  storage   ensures 
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that  no  task  will  be  blocked  permanently  from  execution 
because  it  cannot  get  memory  space.  If  a  task  has  memory 
space  and  is  blocked  while  waiting  for  another  resource,  its 
pages  will  gradually  migrate  to  auxiliary  storage  enabling 
other  tasks  to  get  space. 

The  deadlock  prevention  method  used  in  the  allocation  of 
devices  is  less  sophisticated  than  that  used  for  main 
storage  or  files.  In  fact  it  can  be  considered  as  no  method 
at  all.  The  issue  is  avoided  by  forcing  tasks  which  cannot 
allocate  devices  to  be  rerun  at  a  later  time,  in  the  hope 
that  allocation  will  be  possible  when  rerun  is  attempted. 
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V.   CONCLUSIONS 


Studying  the  resource  allocation  technigues  of  CS/360 
and  MTS  has  revealed  strengths  and  weaknesses  in  both 
systems.  Possibly  at  some  time  in  the  future  an  operating 
system  will  be  developed  which  incorporates  the  good 
features  and  eliminates  the  poor  features  of  both  systems. 

An  advantage  of  OS/360  over  MIS  is  that  OS  does  not 
reguire  interaction  with  the  operator  during  the  normal 
allocation  cf  devices.  In  a  production  environment  where  a 
majority  of  the  I/O  is  not  of  the  unit  record  type,  much 
time  would  be  lost  waiting  for  the  operator  to  choose  a 
device  and  type  in  his  response. 

Both  systems  use  undesireable  methods  vhen  the 
allocation  of  all  reguested  resources  is  not  possible  at  the 
time  of  the  request.  Under  OS  the  operator  is  given  an 
option  which  includes  cancelling  the  job  or  waiting  for 
resources.  If  he  chooses  to  cancel  the  job,  it  is  flushed 
out  of  the  system.  Why?  Since  OS  requires  collective 
allocation  of  resources,  the  task  has  not  yet  begun  to 
execute.  It  would  seem  logical  to  place  the  job  back  on  the 
input  gueue  and  attempt  to  run  it  later.  If  the  operator  is 
reluctant  to  cancel  the  job  and  puts  it  into  a  wait  the 
initiator  is  tied  up  during  this  period  and  cannot  begin 
another  job  step.  This  is  especially  dangerous  when  the 
operator  has  no  idea  how  long  this  wait  may  be.  If  he  is 
not  careful  he  may  seriously  degrade  the  performance  of  the 
system.  lor  example,  this  could  happen  if  he  put  mere  than 
one  job  into  a  wait  when  the  resource  reguired  was  being 
held  by  a  job  which  will  run  for  several  hours. 
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Under  HTS  the  situation  is  different.  when  a  task  is 
put  into  a  wait  condition  it  does  not  hamper  the  execution 
of  the  retraining  tasks  and  will  not  prevent  other  tasks  from 
beginning  to  execute.  The  drawback  comes  when  a  task  is 
terminated  and  returned  to  the  input  queue.  Since  MTS 
allows  allocation  of  resources  at  any  time,  it  is  possible 
that  a  major  file  modification  could  have  been  in  progress 
or  completed  at  the  time  the  job  was  requeued.  Arbitrarily 
rerunning  such  a  job  can  cause  serious  file  integrity 
problems.  It  becomes  the  user's  responsibility  to  avoid 
rerun  under  this  type  of  condition. 

In  the  areas  of  memory  and  file  management,  MTS  utilizes 
the  most  effective  techniques.  Under  OS  a  task  requires  a 
contiguous  area  of  main  storage  to  execute.  The  rapid 
reallocation  of  memory  that  occurs  during  multiprogramming 
tends  to  fragment  the  available  memory  space.  Cften  a 
region  cannot  be  allocated,  even  though  enough  free  space 
exists,  because  this  space  is  not  contiguous.  The  paging 
method  of  MTS  alleviates  two  problems:  first,  the  entire 
task  does  not  have  to  be  in  main  storage  at  one  time,  and 
second,  the  portion  of  the  task  which  is  in  main  storage 
dees  not  require  a  contiguous  area. 

Under  OS  the  only  files  which  can  be  used  concurrently 
are  direct  access  files.  If  a  user  wishes  to  share  a  disk 
file  with  ethers  he  has  no  way  of  restricting  it  to  specific 
users  and,  even  then,  nis  restriction  is  only  in  effect 
during  the  time  that  the  file  is  allocated  to  him.  MIS  not 
only  gives  the  owner  of  a  file  the  ability  to  share  it  with 
other  users,  but  also  the  ability  to  restrict  the  type  of 
access  granted  to  each.  Also,  these  restrictions  are 
permanently  associated  with  the  file  and  are  not  in  effect 
just  while  the  owner  has  the  file  allocated  to  one  of  his 
tasks. 
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As  far  as  system  deadlock  is  concerned,  it  appears  that 
both  systems  prevent  deadlock  but  the  methods  used  can  at 
times  b€  very  costly.  Unfortunately  it  is  much  simpler  to 
point  out  the  shortcomings  of  either  system  than  to  present 
an  alternative  solution. 
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APPENDIX  A 


This  appendix  contains  explanations  of  IBM   terms   used 
in  discussing  resource  allocation  in  OS/360. 

Allocate  Work  Table:  The  Allocate  Work  Table  is  constructed 
by  a  submodule  of  the  I/O  Device  Allocation 
routine.  The  table  contains  an  entry  for  each  DD 
statement  in  the  input  stream.  Each  entry  contains 
information  which  describes  the  data  set  and 
information  that  is  used  in  allocating  a  device  to 
it.  This  information  includes  the  number  of 
volumes  in  the  data  set,  the  number  of  devices 
reguested,  the  number  of  devices  allocated,  the 
number  of  devices  shared,  the  DD  number,  the  number 
cf  devices  available  for  allocation,  and  a  bit 
pattern  representing  which  devices  are  eligible  for 
allocation. 

Job  Control  Table:  The  Job  Control  Table  is  created  by  the 
interpreter  and  placed  in  the  input  queue.  It 
contains  information  from  the  JOB  statement,  job 
status  information,  and  pointers  to  other  tables  in 
the  job's  input  queue  entry.  It  also  contains  the 
job  region  size,  number  of  Step  Input/Output 
Tables,  and  whether  the  job  is  to  have 
checkpoint/restart  [IBM  1972a]. 

Link  Pack  Area:  The  Link  Pack  Area  is  a  region  at  the  top 
(highest  addresses)  of  main  storage.  This  area 
contains  useful  re-entrant  routines  and  tables 
which  remain  core  resident.  These  routines  and 
tables   are   generally   highly  used  and  having  them 
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core  resident  eliminates  the  time  required  to  read 
them  in  from  disk  or  drum.  Which  routines  are  to 
be  included  in  the  Link  Pack  Area  is  determined 
before  the  system  is  generated  [ Flores  1973]. 

Queue  Control  Record:  The  Queue  Control  Record  is  made  up 
cf  a  series  of  pointers  to  entries  in  the  gueue. 
One  entry  points  to  the  highest  priority  job  in  the 
gueue.  The  remaining  15  entries  point  to  the  last 
job  entered  into  the  gueue  for  each  priority.  (The 
elements  within  the  gueue  are  chained  from  highest 
to  lowest  priority,  with  jobs  within  a  priority 
arranged  in  order  of  entry.)  The  organization  of 
the  Queue  Control  Record  facilitates  removing  the 
highest  priority  job  from  the  gueue  or  entering 
jobs  to  the  end  of  each  priority  string  [IBM 
1972a]. 

Step  Control  Table:  The  interpreter  constructs  a  Step 
Control  Table  for  each  step  of  a  job.  This  table 
describes  the  job  step  and  is  utilized  by  the 
initiator  in  making  allocations.  It  contains  the 
step  name,  program  name,  maximum  step  running  time, 
number  of  Step  Input/Output  Tables,  step  completion 
code,  pointers  to  the  first  Step  Input/Output  Table 
and  the  next  Step  Control  Table,  and  other  pointers 
and  status  information  [  IBM  1972a]. 

Step  Input/Output  Table:  The  interpreter  creates  a  Step 
Input/Output  Table  for  each  DD  statement  in  the 
input  stream.  This  table  completely  describes  the 
data  set,  its  I/O  device  reguirements,  and  contains 
a  pointer  to  the  next  Step  Input/Output  Table  for 
the  step.  The  information  contained  in  the  table 
is    used   by   the   initiator   to   build   the   Task 
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Input/Output  Table  and  is  used   by   the   Allocation 
and  Disposition  routines  [IBM  1972a]. 

Supervisor  Queue  Space:  The  Supervisor  Queue  Space  is  a 
region  of  main  storage  just  above  the  Nucleus.  It 
contains  control  blocks,  lists,  and  tables  reguired 
by  the  control  program.  The  maximum  size  of  this 
area  is  specified  at  system  generation  time  and 
space  is  allocated  and  freed  from  within  this  area 
as  reguired  during  execution  [Flores  1973  ]. 

Task  Input/Output  Table:  The  Task  Input/Output  Tatle  is 
contructed  by  job  management  routines.  It  resides 
in  main  storage  during  step  execution  and  provides 
information  to  various  I/O  routines.  The  table 
contains  the  job  name  and  step  name.  It  also 
contains  an  entry  for  each  data  set  reguested  for 
the  step.  This  entry  contains  such  information  as 
label  processing  insructions,  rewind  and  unloading 
instructions,  unit  affinity  or  channel  separation 
reguirements,  and  volume  mounting  instructions  [IBM 
1972b]. 

Unit  Control  Block:  There  is  a  Unit  Control  Elock  for  each 
device  on  the  system.  It  contains  information 
describing  the  device  characteristics,  the  current 
device  status,  the  internal  job  identification,  the 
protection  .key  of  the  job,  the  serial  number  of  the 
volume  assigned  to  the  device,  label  information,  a 
pointer  to  the  device  error  routine,  and  other 
information  reguired  by  to  the  I/O  supervisor  and 
job  scheduler.  Each  Unit  Control  Block  contains 
two  segments,  a  segment  containing  information 
ccmmon  to  all  devices  and  a  segment  containing 
device  peculiar  information  [IBM  1972b]. 
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APPENDIX  B 


The  macrcs  described  below  can  each  be  thought  of  as  an 
interface  to  a  system  routine.  When  the  Assembler 
encounters  cue  of  these  macros  it  generates  a  series  of 
instructions  to  pass  parameters  and  originate  a  supervisor 
call  (SVC)  .  At  executior.  time  the  SVC  instruction  causes  an 
interrupt.  The  SVC  interrupt  handler  determines  the  type  of 
SVC  and  rcutes  control  to  the   appropriate   system   rcutine. 

ATTACH:  The  ATTACH  macro  causes  the  control  program  to 
create  a  new  task  and  indicates  the  entry  point  in  the 
program.  The  new  task  is  a  subtask  of  the  task  which 
issued  the  ATTACH  macro  and  it  assumes  the  dispatching 
priority  of  the  originating  task.  The  issuing  urogram 
can  prcvide  the  attached  task  with  a  parameter  list, 
an  exit  routine  to  be  given  control  when  the  task 
terminates,  and  a  control  block  in  which  to  post  its 
termination.  If  a  usable  copy  of  the  program  tc  be 
given  control  is  not  in  main  storage,  it  is  loaded 
[IBM  1972c]. 

DEQ:  The  DEQ  macro  causes  the  control  program  to  remove 
control  of  one  or  more  serially  reusable  resources 
from  the  issuing  task.  The  DEQ  macro  must  be  used  to 
release  every  resource  obtained  through  the  use  of  the 
EN£  macro.  If  a  task  attempts  normal  termination 
while  it  still  has  control  of  any  resources  assigned 
through  an  ENQ,  it  will  te  abnormally  terminated  [IBM 
1972c]. 

ENQ:  The  ENQ  macro  reguests  that  the  control  program 
symbolically   assign   control   of  one  cr  more  serially 
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reusable  resources  to  the  task  issuing  the  nacro. 
Access  to  a  resource  is  logically,  not  physically 
restricted.  This  means  that  a  task  may  use  a  serially 
reusable  resource  without  using  the  ENQ  macro,  but 
results  of  doing  so  may  be  unreliable.  Once  control 
of  a  resource  is  symbolically  obtained  by  a  task,  it 
remains  until  that  task  issues  a  DEQ  macro  specifying 
the  same  resource  [IBM  1972c]. 

FREIMAIN:  The  FREEMAIN  macro  asks  the  control  program  to 
free  space  that  is  no  longer  needed.  The  space  which 
can  be  freed  is  any  space  obtained  through  the  use  of 
the  GETMAIN  macro.  The  space  is  freed  by  adding  gueue 
elenents  representing  the  space  to  chains  recording 
free  areas  of  main  storage.  If  the  area  to  be  freed 
is  a  region,  the  FREEMAPN  routine  issues  a  PREEPART 
macro.  Upon  completion,  control  returns  to  the 
calling  routine  [IBM  1972d]. 

FREEPART:  The  FREEPART  routine  is  entered  from  the  EEEEMAIN 
routine.  Its  first  function  is  to  use  the  Task 
Ccntrol  Block  representing  the  task  to  locate  the 
partition  gueue  element  of  the  appropriate  region.  A 
FREEMAIN  is  then  issued  to  release  the  space  in  the 
Supervisor  Queue  Area  occupied  by  the  partition  gueue 
element.  Next,  if  the  region  to  be  freed  is  adjacent 
to  an  existing  free  area,  it  is  combined  with  that 
area.  If  not,  an  element  representing  the  region  is 
added  to  the  chain  of  free  areas.  Finally,  if  there 
is  an  initiator  waiting  for  a  region  it  is  notified 
and  control  returns  to  FREEMAIN  [IBM  1972d]. 

GETKAIN:  The  GETMAIN  macro  is  used  for  all  reguests  for 
space  in  main  storage.  These  include  reguests  for 
regions,  space  within  regions,  and  space  within  the 
Supervisor  Queue   Area.    The   GETMAIN   routine   scans 
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queues  of  elements  that  represent  available  space  to 
locate  the  amount  of  space  of  the  type  requested. 
When  the  space  is  found,  the  affected  queues  are 
updated  indicatinq  that  the  space  is  no  lonqer 
available  and  the  address  of  the  space  is  returned  to 
the  reguester.  If  the  request  is  for  a  region  the 
GETMAIN   routine  issues  the  GETPART  macro  [IBM  1972d]. 

GE1EART:  The  GETPART  routine  is  entered  via  the  GETMAIN 
routine.  It  first  determines  whether  there  is  enouqh 
space  in  the  Supervisor  Queue  Area  to  initiate  the  job 
step  and  whether  there  is  enouqh  free  space  in  the 
dynamic  area  to  iulfull  the  request.  If  there  is  not 
enough  space  available,  the  initiator  is  put  into  a 
wait  state  and  control  passes  to  the  highest  priority 
ready  task  in  the  system.  If  the  requested  space  is 
available,  the  GETPART  routine  issues  a  GETMAIN  to 
obtain  space  in  the  Supervisor  Queue  Area  for  the 
partition  queue  element.  The  GETPART  routine  then 
adjusts  the  pointer  in  the  partition  queue  element  to 
point  to  the  newly  acquired  reqion  and  returns  control 
to  GETMAIN  [IBM  1972d]. 
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APPENDIX  C 


This  appendix  presents  a  detailed  description  cf  job 
initiation  under  OS/360.  Readers  unfamiliar  with  CS/360 
should  refer  to  Appendix  A  and  Appendix  B  for  explanations 
of  IBM  terms  and  system  macro  instructions. 

The  initiator  is  composed  of  many  modules,  each  with  a 
specific  function.  Some  of  these  modules  are  permanently 
core  resident  in  the  Link  Pack  Area,  others  are  brought  into 
core  only  as  they  are  needed.  The  flow  of  control  depends 
upon  the  characteristics  of  the  job  being  initiated  and  upon 
the  availability  of  the  resources  requested. 

The  discussion  below  follows  the  flow  of  control  through 
the  initiator  modules  during  the  initiation  of  a  typical 
job.  Coverage  is  limited  to  resource  allocation  and  is  not 
concerned  with  other  housekeeping  functions  which  do  not 
affect  deadlcck  prevention. 

A.   JOB  S  EL  EC  HON 

The  Job  Selection  routine  must  first  determine  if  there 
is  a  job  in  the  input  queue  which  can  be  initiated  by  this 
initiator.  lo  do  this  it  issues  an  ENC.  macro  on  the  queue 
control  record  to  obtain  exclusive  control  cf  it.  When  the 
queue  control  record  becomes  available  it  is  read  into  core 
and  examined.  If  there  is  no  job  in  the  input  queue  a  DEQ 
macro  is  issued,  freeing  the  queue  ccntrcl  reccrd.  A 
message  is  then  sent  to  the  console  informing  the  operator 
that  the  initiator  is  waiting  for  work.  Control  passes  to 
the  Initiator  Wait  routine  resident  in  the  Link  Pack  Area 
which  frees  the  core  held  by  the  initiator.   When  a   jcb   is 
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placed  in  the  input  queue  the  Initiator  Wait  routine  is 
notified.  It  then  obtains  a  new  region  of  main  storage  and 
passes  control  to  the  Job  Selection  routine. 

If  there  are  jobs  in  the  input  queue,  the  highest 
priority  jot  is  selected.  The  queue  control  record  is 
updated  to  indicate  the  selection  and  is  written  back  into 
the  queue.  Ihen  a  DEQ  macro  is  issued  permitting  access  to 
the  queue  control  record  by  other  routines. 

The  job  control  table  describing  the  selected  job  is 
read  into  cere.  From  it  is  extracted  the  number  of  steps  in 
the  job  and  the  location  of  the  step  control  table  for  each 
step.  The  step  control  table  for  the  first  job  step  to  be 
initiated  is  now  read  into  core. 

The  dispatching  priority  of  the  initiator  is  changed  to 
the  priority  specified  for  the  job.  Reducing  the 
initiator's  priority  forces  its  contention  for  system 
resources  (e.g.  the  CPU)  to  be  at  a  priority  equal  to  that 
of  the  job  being  initiated. 

Next  the  Job  Selection  routine  reads  into  "core  the  table 
containing  the  name  and  disposition  of  all  non-temporary 
data  sets  required  by  the  entire  job.  With  this  information 
it  builds  a  parameter  list  for  the  ENQ  macro  specifying  each 
data  set  name  and  whether  its  use  is  exclusive  or  shareable. 
When  the  parameter  list  is  completed  it  is  written  into  the 
Supervisor  Queue  Space  and  control  is  passed  to  the 
Determine  Region  Size  routine. 

B.   REGION  MANAGEMENT 

The  modules  of  the  initiator  operate  in  various  regions 
of  main  storage.  When  the  initiator  is  first  entered  it 
operates  in  a  region  obtained  for   it   by   the  System   Task 
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Control   routine.    After  that,  main  storage  is  obtained  and 
released  by  the  initiator  modules  in  the  Link  Pack  Area. 

The  Determine  Region  Size  routine  compares  the  region 
size  reguested  by  the  job  with  the  minimum  region  size 
reguired  to  initiate  a  job  step.  It  determines  the  step 
region  size  as  the  greater  of  the  two.  It  then  stores  this 
region  size,  along  with  other  information  not  pertinent  to 
this  discussion,  into  a  work  table  and  writes  it  into  the 
Supervisor  Cueue  Space.  The  location  of  the  work  table  is 
passed  tc  the  Get/Free  Region  routine. 

The  Get/Free  Region  routine  resides  in  the  link  Pack 
Area.  When  it  is  entered,  it  frees  the  old  region  used  by 
the  initiator  and  issues  the  ENQ  macro  for  data  sets  using 
the  parameter  list  created  by  the  Job  Selection  routine.  If 
the  routine  is  unable  to  obtain  all  of  the  data  sets 
specified,  it  issues  a  DEQ  to  free  those  obtained.  It  then 
sends  a  message  to  the  console  notifying  the  operator  cf  the 
data  sets  not  available.  The  operator  is  given  the  option 
of  retrying  the  ENQ,  cancelling  the  job,  or  waiting  fcr  the 
data  sets  to  become  available. 

When  the  ENQ  is  completed,  the  storage  occupied  ty  the 
parameter  list  is  freed.  The  GE1PART  macro  is  then  issued 
to  ofctain  the  region  specified  in  the  work  table.  When  it 
has  obtained  the  region  of  main  storage,  control  is  passed 
to  the  Allocation  Interface  routine  which  is  loaded  into  the 
new  region. 

C.   I/O  DEVICE  ALLOCATION 

The  Allocation  Interface  routine  releases  the  core  used 
by  the  fcork  table,  does  some  routine  status  checking  which 
need  not  be  discussed,  and  calls  the  I/O  Device  Allocation 
routine   as  a  subroutine.   The  I/O  Device  Allocation  routine 
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is  Hade  up  of  submodules,  therefore   numerous   module   names 
will  appear  in  this  section. 

Since  both  the  I/O  Device  Allocation  and  Ter miration 
routines  codify  the  unit  control  blocks  and  may  be  operating 
concurrently  on  seperate  system  tasks,  the  unit  control 
block  tafcle  must  be  protected  from  multiple  accesses.  To 
prevent  this  the  Allocation  Entry  routine  issues  an  ENQ  on 
the  table  for  the  I/O  Device  Allocation  routine.  Since  the 
ENQ  is  issued  at  the  beginning  of  the  routine  the  effect  is 
to  prevent  allocation  from  being  performed  for  more  than  one 
jot  step  at  a  time. 

When  the  Housekeeping  routine  receives  control  it  issues 
an  ENQ  on  the  unit  control  blocks  in  the  name  of  the 
Tenrinaticn  routine.  This  prevents  termination  of  any  job 
step  while  housekeeping  is  taking  place.  This  routine  also 
issues  an  ENQ  on  the  unit  control  blocks  to  prevent 
allccation  routines  for  another  task  from  using  them  during 
this  allocation  processing. 

The  Housekeeping  routine  analyzes  the  reguests  for  I/O 
devices  and  stores  the  information  necessary  for  allccation 
in  tabular  form  for  reference  by  the  allocation  routines. 
It  also  references  the  system  catalogue  in  order  to  add 
volume  information  to  existing  tables,  such  as  the  Step 
Control  Table  and  the  Step  Input/Output  Table. 

Before  the  Housekeeping  routine  passes  control  to  the 
Allocation  Control  routine,  it  issues  a  DEQ  to  allow 
Tenrinaticn  to  have  access  to  the  unit  control  blocks  while 
Allccation  Control  is  building  tables.  The  tables  built  at 
this  time  are  numerous;  a  detailed  description  of  each  would 
be  impractical  and  would  not  contribute  to  meeting  the  goals 
of  this  paper.  Most  of  the  tables  are  not  completed  at  this 
time   but   are   filled   by  other  modules.   At  this  pcint  the 
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space  required  for  each  is  determined,  main  storage  is 
allocated,  and  a  control  table  which  points  to  them  is 
built. 

The  Eemand  Allocation  routine  is  entered  free  the 
Allocation  Control  routine.  It  issues  an  ENQ  on  the  unit 
control  blocks  to  prevent  access  by  the  Termination  routine 
and  then  tegins  to  build  tables.  The  first  table  filled  in 
is  the  allocate  work  table.  The  allocate  work  table  entry 
contains  information  describing  the  data  set  and  other 
information  required  for  device  allocation.  This 
information  is  obtained  primarily  from  other  tables  such  as 
the  Step  Input/Output  Table.  Using  the  information  now  in 
the  allocate  work  table,  a  search  is  made  of  the  unit 
control  blocks  for  all  devices  which  would  satisfy  the 
requirements  of  the  data  set.  A  bit  pattern  representing 
these  devices  is  stored  in  the  allocate  work  table. 

Next  the  channel  load  table  is  filled  in.  for  the 
purpose  of  allocation,  the  load  on  a  channel  is  defined  as 
the  number  of  data  sets  which  are  currently  accessible 
through  that  channel.  The  channel  load  table  contains  an 
entry  for  each  logical  channel  in  the  system. 

When  the  Demand  Allocation  routine  has  finished  building 
tables,  it  then  begins  making  unit  assignments.  It  first 
makes  all  assignments  for  resident  direct  access  volumes. 
It  then  determines  which  devices  are  not  eligible  for 
allocation  and  eliminates  them  from  the  range  of 
consideration.  A  device  is  ineligible  if  it  is  off-line, 
contains  a  resident  volume,  or  has  been  allocated.  The 
device  is  eliminated  from  the  range  of  consideration  by 
setting  the  bit  corresponding  to  the  device  to  zero  in  the 
bit  pattern  of  the  allocate  work  table  entry.  The  final  bit 
pattern  represents  only  devices  which  can  satisfy  the 
reguest. 
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Finally,  all  explicit  and  implicit  requests  for  specific 
devices  are  honored.  If  there  are  still  outstanding 
requests  at  this  point,  control  is  passed  to  the  Decision 
Allocation  routine;  otherwise,  control  is  passed  to  the  Task 
Input/Output  Table  (TIOT)  Construction  routine. 

The  Decision  Allocation  routine  first  examines  each 
allocation  request  and  determines  which  units  could  he  used 
to  fulfill  them.  Ihis  decision  takes  into  account  requests 
for  channel  separation  between  data  sets,  requests  for  data 
sets  to  fce  on  the  same  device,  and  that  data  sets  passed 
from  prior  job  steps  are  already  mounted  on  specific 
devices.  When  the  range  of  eligible  devices  has  been 
reduced  as  much  as  possible,  allocation  begins.  Data  sets 
are  selected  for  allocation  beginning  with  the  most 
restrictive  requests.  When  the  data  set  has  been  selected, 
devices  are  considered  in  the  following  order:  a  device  on 
the  channel  with  the  greatest  number  of  free  units,  a  device 
on  the  channel  with  the  lightest  work  load,  or  the  first 
device  in  the  unit  control  table.  The  number  of  free  units 
is  determined  by  consulting  the  unit  control  blocks  and  the 
channel  work  load  is  obtained  from  the  channel  load  table. 
When  a  device  is  chosen  it  is  eliminated  from  the  list  of 
eligible  devices  for  all  other  data  sets  and  the  next  data 
set  is  selected  for  allocation.  When  allocations  have  been 
made  for  all  requested  data  sets,  control  is  passed  to  the 
TIOT  Construction  routine. 

If  allocation  is  impossible  because  of  lack  of  devices, 
the  operator  is  given  the  option  of  cancelling  the  job, 
making  a  device  available  which  is  offline,  or  waiting  for 
devices  to  become  available.  If  the  wait  option  is 
selected,  the  Wait  for  Deallocation  routine  is  entered.  The 
Wait  for  Unallccation  routine  issues  two  DEQ's  which  allow 
access  to  the  unit  control  blocks  by  the  Termination  routine 
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and  by  allocation  routines  for  other  tasks.  These  two  DEQ's 
correspond  to  the  two  ENQ's  issued  in  the  Housekeeping 
routine.  When  a  task  terminates,  freeing  its  I/O  devices, 
control  returns  to  the  Wait  for  Unallocaticn  routine  which 
issues  two  ENQ's  on  the  unit  control  blocks.  Allocation  is 
then  attempted  again. 

The  HOT  Construction  routine  builds  the  task 
input/output  table.  The  task  input/output  table  is  used  to 
provide  information  to  I/O  support  routines  such  as  OPEN, 
CLOSE,  and  EOV.  The  table  contains  an  entry  for  each  data 
set  reguested  for  the  job  step.  The  HOT  Construction 
routine  also  allocates  direct  access  storage  space  on  public 
volumes. 

The  External  Action  routine  issues  mounting  instructions 
to  the  operator  for  all  volumes  reguired.  If  an  incorrect 
volume  is  mounted  the  operator  is  again  issued  a  mount 
message  containing  the  correct  volume  identification.  After 
all  volumes  have  been  verified  control  is  passed  to  the 
Allocation  Exit  routine. 

The  Allocation  Exit  routine  is  entered  after  all 
allocations  have  been  successfully  made  or  if  an  error 
condition  has  been  detected.  If  the  routine  is  entered 
because  of  an  error  condition  it  sets  a  bit  indicating  that 
the  job  step  should  be  flushed.  If  the  routine  is  entered 
after  allocation  it  writes  the  allocation  messages  into  the 
output  queue.  In  either  case,,  it  issues  two  DEQ's  to  allow 
access  to  the  unit  control  blocks  by  allocation  and 
termination  routines  performing  other  tasks  and  returns 
control  to  the  Allocation  Interface  routine. 
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D.  ATTACHING  TASKS 

By  the  time  the  initiation  process  has  reached  this 
stage  all  of  the  allocations  have  been  completed.  What 
remains  is  gathering  the  information  needed  by  the 
supervisor  to  ran  the  task.  This  information  is  passed  via 
the  ATTACH  macro. 

Upon  the  completion  of  device  allocation,  control 
returns  to  the  Allocation  Interface  routine.  It  tests  the 
condition  of  the  allocation  to  determine  whether  or  not  it 
was  successful;  if  so,  it  proceeds.  The  Table  Breakup 
routine  is  used  to  convert  the  task  input/output  table  into 
a  series  of  records  which  are  added  to  the  task's  input 
gueue  entry.  Next  the  job  control  table  and  the  step 
control  table  are  written  back  into  the  work  gueue  data  set. 

The  Allocation  Interface  routine  now  builds  the 
parameter  list  for  the  ATTACH  macro.  It  also  builds  the 
initiator  parameter  list  which  contains  pointers  to  the 
ATTACH  parameter  list  and  other  pertinent  lists  and  tables. 
Control  is  now  passed  to  the  Pre-Attach  routine. 

The  Pre-Attach  routine  determines  the  priority  at  which 

the   job   step   will   be  attached  and  passes  control  to  the 

Attach  routine  which  issues  the  ATTACH  macro.    When  ATTACH 
has  been  issued,  execution  of  the  job  step  begins. 

E.  TASK  TERMINATION 

A  task  is  terminated  when  it  reaches  normal  conpletion, 
abnormally  ends  execution,  exceeds  its  reguested  time 
interval,  exceeds  its  output  limit,  or  is  cancelled  ty  the 
operator.  When  any  pf  the  above  conditions  is  encountered, 
control  is  given  to  the  Termination  routine  which  functions 
as  a  subroutine  of  the  initiator.   The   Termination   routine 


42 


is    a    collection    of    modules    performing   terniration 
housekeeping,  step  termination,  and  job  termination. 

The  first  module  encountered  is  the  Termination  Entry 
routine.  It  places  termination  messages  into  the  output 
queue  and  if  the  program  ended  abnormally  it  passes  control 
to  the  Indicative  Dump  routine.  The  Indicative  Dump  routine 
writes  a  message  to  the  programmer  indicating  the  user  and 
system  completion  codes  and  passes  control  to  the  Step 
Termination  Ccntrol  routine. 

The  Step  [Termination  Control  routine  determines  whether 
the  step  was  normally  terminated.  If  not,  certain  actions 
are  reguired.  In  this  discussion  a  normal  termination  is 
assummed  and  control  is  passed  to  the  Data  Set  Driver 
routine. 

The  Data  Set  Driver  routine  reads  a  step  input/output 
table  entry  for  the  step  into  main  storage.  It  then  passes 
control  tc  the  Disposition  and  Unallocation  routine  which 
processes  the  data  set  specified  by  the  entry.  Ccntrol 
returns  tc  the  Data  Set  Driver  which  brings  in  the  next  step 
input/output  table  entry.  This  loop  continues  until  all 
entries  for  the  step  have  been  processed;  control  then 
returns  to  the  Step  Termination  Control  routine. 

The  Disposition  and  Unallocation  routine  first  performs 
data  set  disposition  as  specified  in  the  data  definition 
statement.  This  includes  updating  the  system  catalogue  to 
reflect  an  addition  or  deletion  of  a  data  set,  scratching 
space  on  direct  access  volumes,  and/or  passing  data  sets  to 
subsequent  jot  steps.  Next  an  ENQ  macro  is  issued  on  the 
unit  control  blocks  and  the  I/O  device  corresponding  to  the 
data  set  is  unallocated.  If  the  data  set  can  be  demounted 
from  the  device,  a  message  is  sent  to  the  console  informing 
the  operator.   When  unallocation  is  complete  a  DEQ  is  issued 
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freeing   the   unit  control  blocks  and  control  returns  to  the 
Step  Termination  Control  routine. 

If  the  job  step  just  terminated  is  not  the  last  £tep  in 
the  job,  control  passes  to  the  Step  Termination  Exit  routine 
which  returns  contrpl  to  the  calling  routine.  In  this  case 
the  calling  routine  is  the  initiator  which  then  begins 
processing  the  next  job  step.  If  the  job  step  just 
terminated  was  the  last  step  in  the  job  the  Job  Termination 
Control  routine  is  entered. 

The  Job  lermination  Control  routine  examines  the  job 
control  table  to  determine  if  any  data  sets  have  been  passed 
or  retained  which  were  not  referenced  by  a  subsequent  step. 
If  there  are,  the  Disposition  and  Unallocation  routine  is 
used  to  process  them.  When  all  data  sets  have  been 
processed  control  passes  to  the  Job  Termination  Exit 
routine. 

The  Job  Termination  Exit  routine  places  the  last 
teririnaticn  message  into  the  output  queue,  completes  the 
output  gueue  entries,  and  issues  a  job  ended  message  to  the 
operator.  The  initiator  is  now  free  to  process  another  job 
and  the  entire  initiation  process  begins  again. 
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APPENDIX  D 


The  entries  in  this  appendix  describe  MTS  elements  used 
in  communications  between  the  supervisor  and  the  Paging  Drum 
Processor.  The  source  of  information  for  all  five  entries 
is  [Alexander  1971  ]. 

Page  Control  Block:  There  is  a  page  control  block  for  every 
virtual  memory  page  in  the  system.  The  page  control 
block  is  always  on  a  linked  list  of  pages  owned  by  the 
task  and  may  also  be  on  one  of  the  four  system  gueues 
listed  below.  It  contains  the  status  of  the  page.  The 
fields  of  the  page  control  block  are:  the  address  of 
the  next  PCB  for  the  same  task,  the  main  storage 
address  of  the  page,  the  virtual  memory  address  of  the 
page,  the  status  of  the  PCB,  the  address  of  the  PCB  on 
the  system  gueue,  the  number  of  pages  in  the  same 
block,  the  address  of  the  Task  Control  Table  for  the 
task  owning  the  page,  the  number  of  lock  requests  for 
the  page,  a  scratch  area  to  be  used  by  the  supervisor, 
the  storage  key,  the  status  of  the  page,  and  the 
auxiliary  storage  address  of  the  page. 

Page  In  Queue:  This  is  a  gueue  of  all  PCB's  for  pages  which 
have  been  requested  by  the  supervisor,  but  which  the 
Paging  Drum  Processor  has  not  yet  started  to  read  in. 

Page  In  Complete  Queue:   This  is  a  queue  of   all   PCE's  for 

pages   which   have   been   read   in   by   the  Paging  Drum 

Processor,  but  of   which   the   supervisor   is   net  yet 
aware. 
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Page  Out  Cueue:   This  is  a  queue  of  all  PCB's  for   cages  in 

main   storage   which   can  be  paged  out  if  more  space  is 

reguired.    The   PCB's   are   arranged    in    order  of 
desirability  of  removal. 

Release  Page  Queue:  This  is  a  queue  of  PCB's  for  all  pages 
which  have  been  released  by  their  tasks,  but  which  have 
not  yet  teen  released  by  the  Paging  Drum  Processor. 
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APPENDIX  E 


entries  in  this  appendix  describe  supervisor  calls 
y  the  Paging  Drum  Processor.  The  source  of 
tion  for  all  five  entries  is  [Alexander  197  1]. 

lues:  This  supervisor  call  is  used  by  the  Paging  Drum 
>oc€££cr  to  get  the  Page  In  Queue  and  the  Release  Page 
)eue. 

.1   Page:    This  supervisor  call  is  used  by  the  Paging 

urn  Processor  to  request  a  main  storage  block.    If   a 

;.ock   is  available  it  is  allocated  to  the  page  and  the 

:ldress  is  returned  in  the  page  control  block.    If   no 

:.ock  can  be  allocated  a  condition  code  so  indicates. 

i.te  Page:  This  supervisor  call  is  used  by  the  Paging 
l:um  Processor  to  request  the  number  of  pages  required 
b  fill  the  empty  slots  on  the  paging  drum  fcr  the 
evolution  being  scheduled.  The  supervisor  will  return 
b  to  the  number  of  pages  requested,  depending  en  their 
/ailafcility  and  how  full  memory  is. 

sal  Page:  This  supervisor  call  is  used  by  the  faging 
rum  Processor  to  inform  the  supervisor  that  a  fclcck  of 
ain  storage  is  now  available  for  reallocation.  It  is 
lso  used  by  the  supervisor  to  notify  the  PDP  that  the 
age  was  reclaimed  by  its  task  while  it  was  being 
ritten  out  to  the  drum.  In  this  case  the  PDF  marks 
he  copy  of  the  page  on  auxiliary  storage  as  invalid. 

it:  This  supervisor  call  is  used  by  the  Paging  Drum 
rccesscr  to  inform  the  supervisor  that  it  has  no   more 
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work  tc  do.  Therefore  the  next  tine  the  EDF  is 
required  it  will  have  to  be  restarted  by  the 
supervisor. 
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